Developers.IO 2017セッション「AWSで始めるビッグデータ分析」で話しました #cmdevio2017

Developers.IO 2017

#イベント

八幡豊

2017.07.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「AWSで始めるビッグデータ分析」を発表しました。そのレポートです。

発表スライド

セッションの概要

セッションの対象者

AWS初級者向けの位置付けで、以下のような方を対象としました。

AWSでデータ分析を始めたい(…何から始めたらよいかわからない)
AWSでデータ分析基盤を構築するためのベストプラクティスを知りたい
AWSの利用経験がある(VPC, EC2, RDS, S3, etc.)

アジェンダ

パイプラインで考えるデータ分析基盤
- AWSでデータ分析基盤を構築する際の、AWSサービス選択の考え方
データ分析に効くAWSサービス
- データ分析向けのAWSサービスの紹介
データ分析リファレンスアーキテクチャ
- セッションで触れたAWSサービスを使ったデータ分析アーキテクチャパターンの紹介

パイプラインで考えるデータ分析基盤　

AWSにはデータ分析で利用できるサービスが豊富にあります。これらを利用すれば安く、早く、スケーラブルなデータ分析基盤を構築することができます。一方で、実現したい分析要件に対してどのサービスを選択すればよいか？を迷われる方も多いかと思います。

本セッションではデータ分析基盤を構築時のAWSサービスの選択のポイントとして以下を挙げました。

データ分析をパイプラインで考える
- 収集、前処理、保存、分析、可視化
AWSの各サービスが何に最適化されているか？また最適化された結果のトレードオフは何か？を理解する
- スループット、レイテンシー、スケーラビリティ、扱えるデータタイプ／データ構造、カスタマイズ性、上限値、コスト
各サービスの特徴を理解した上で、パイプライン上のそれぞれのジョブに最適なサービスを選択する

またパイプラインのそれぞれの工程ごとに、サービス選択の着眼点をご紹介しました。

収集

データタイプに着目

ファイル：Amazon S3へアップロード
ストリームデータ：Amazon Kinesis Streams、Amazon Kinesis Firehose、AWS IoTで収集
収集したデータはS3に集約する
- ストリームデータについてもリアルタイムに処理すると同時にS3にアーカイブしておく

前処理(データ変換)

ワークロードに着目

バッチ：スループット重視
- Amazon EMR、Amazon EC2で処理
リアルタイム：レイテンシー重視
- AWS Lambda、Amazon Kinesis Analyticsで処理

分析・保存

ここでの「保存」は、前処理したデータの保存先、という観点でお話ししました。

データ構造、アクセスパターンに着目

固定されたスキーマ
- 多数のユーザーからの同時アクセス：Amazon RDS
- 大規模データの集計・抽出：Amazon Redshift
- Amazon RDSとAmazon Redshiftとも分析のためにデータをそれぞれのストレージにロードする必要がある(腹持ちする必要がある)
- Amazon Redshift Spectrumを使うとデータをロードせず、Amazon S3上のファイルに直接クエリができる
スキーマレス
- シンプルなクエリ、低レイテンシーを求めて：Amazon DynamoDB
- 大規模データの集計・抽出：Amzon S3 + Amazon EMR、 Amazon S3 + Amazon Athena
- 全文検索：Amazon ElasticSearch Service、Amazon CloudSearch

可視化

データの提供方法に着目

セルフBI：Amazon QuickSight
定型レポート：カスタムWebアプリケーションを開発
- サーバーレス構成：Amazon DynamoDB + AWS Lambda + Amazon API Gateway + Amazon S3
- オーソドックスなWeb + DB構成：Amazon RDS + Amazon EC2
ログ分析のダッシュボード：Amazon ElasticSearch Service(Kibana)

データ分析に効くAWSサービス

データ分析で利用する主要サービス(独断と偏見)として以下の6サービスの概要、利用上の注意点などをご紹介しました。

Amazon Redshift(Spectrum含む)
Amazon EMR
Amazon Athena
Amazon Kinesis Streams
Amazon Kinesis Firehose
Amazon Kinesis Analytics
Amazon QuickSight

Amazon Redshift(Spectrum含む)

DWH特化の高速RDB
分散処理
PostgreSQL互換のSQLが使える
性能を引き出すためにはテーブル設計(分散キー、ソートキー、圧縮タイプ)が重要
Amazon Redshift Spectrumを使うとS3上のデータに直接クエリが投げられる

Amazon EMR

マネージドHadoopクラスター
- 分散処理
- S3をデータストアとして使える
- DynamoDBやKinesis Streamsのデータにも直接アクセスできる
Amazon RedshiftとAmazon EMRの比較
- どちらも分散処理ができる
- 構造化データ：Redshift、非構造化、半構造化データ：Amazon EMR
- よくあるパターン：EMR(Hadoop)で非構造化／半構造化データを構造化データへ変換しRedshiftへロード

Amazon Athena

マネージドPresto。S3に対してクエリを投げられる
Amazon RedshiftやAmazon EMRを利用するにはクラスターを起動する必要があるが、
Amazon Athenaはサーバーレス
主にはアドホッククエリ向けのサービス

Amazon Kinesis Streams

ストリームデータの収集と保存。保存期間は24時間〜最大7日間
データの入力から取得までの遅延は通常1秒未満
スループットやデータ量に応じてスケールイン／アウト可能(シャードの分割、統合)

Amazon Kinesis Firehose

ストリームデータの収集と配信
プログラム開発不要、設定のみでAmazon S3、Amazon Redshift、Amazon ElasticSearch Serviceにデータを配信できる
遅延は最短で60秒〜最大900秒
スループットに応じて自動スケール

Amazon Kinesis StreamsとAmazon Kinesis Firehoseの比較

まずはAmazon Kinesis Firehoseを検討
60秒のレイテンシーが許容できない、Amazon S3、Amazon Redshift、Amazon ElasticSearch Serviceに配信する以外のことをやりたい場合はAmazon Kinesis Streamsを選択
Amazon Kinesis Firehoseの東京リージョン上陸を期待して待ちましょう

Amazon Kinesis Analytics

ストリームデータに対してSQLクエリを実行できる
Kinesis Streams/FirehoseからInput → Kinesis Streams/FirehoseにOutput
スループットに応じて自動スケール

Amazon QuickSight

マネージドBIサービス
AWS内外のデータソースに接続できる
"SPICE"にデータを取り込むことで高速な分析ができる

データ分析リファレンスアーキテクチャ

最後にリファレンスアーキテクチャとして、以下の分析シナリオでのアーキテクチャパターンをご紹介しました。アーキテクチャ図はスライドをご参照ください。

売上分析

オンプレミスのDBにある売上データ
以下の分析環境を提供
- 生データに対するアドホック分析
- セルフBI
- 定型レポート
利用するサービス
- Amazon S3
- Amazon EMR
- Amazon Athena
- Amazon Redshift
- Amazon QuickSight
- Amazon RDS
- Amazon EC2

ログ分析

Webアプリケーションの行動ログとアクセスログ
行動ログはBIツールで分析
アクセスログは、
- リアルタイムダッシュボードで可視化
- 特定のしきい値を超えたものをチャットに通知
利用するサービス
- Amazon Kinesis Streams
- Amazon Kinesis Firehose
- Amazon Kinesis Analytics
- Amazon Athena
- Amazon Redshift
- Amazon QuickSight
- Amazon ElasticSearch Service
- AWS Lambda